YR_DB_RUNTIME_VERIF: A FRAMEWORK FOR 
VERIFYING SQL CORRECTNESS 
PROPERTIES OF GUI SOFTWARE AT 
RUNTIME 


Xavier Noumbissi Noundou 


yeroth.d@gmail.com 


Abstract. Software correctness properties are essential to maintain 
quality by continuous and regressive integration testing, as well as run- 
time monitoring the program after customer deployment. This paper 
presents an effective and lightweight C++ program verification framework: 
YR_DB_RUNTIME_VERIF, to check SQL (Structure Query Language) 
software correctness properties specified as temporal safety properties [11]. 
A temporal safety property specifies what behavior shall not occur, in 
a software, as sequence of program events. YR_DB_RUNTIME_VERIF allows 
specification of a SQL temporal safety property by means of a very small 
state diagram [29]; such a state diagram, would only be specified by a 
start and an accepting state, and by a pre- and post-condition on the 
state diagram transition between them. In YR_DB_RUNTIME_VERIF, a spec- 
ification characterizes effects of program events (via SQL statements) on 
database table columns by means of set interface operations (€, ¢), and, 
enable to check these characteristics hold or not at runtime. Integration 
testing is achieved for instance by expressing a state diagram that en- 
compasses both Graphical User Interface (GUI) states and MySQL 
databases queries that glue them. For example, a simple specification 
would encompass states between "Department administration’ and ’Stock 
listing’ GUI interfaces, and transitions between them by means of MySQL 
databases operations. YR_DB_RUNTIME_VERIF doesn’t generate false warn- 
ings; YR_DB_RUNTIME_VERIF specifications are not desirable (forbidden) 
specifications (fail traces). This paper focuses its examples on MySQL 
database specifications, labeled as states diagrams events, for the newly de- 
veloped and FOSS (Free and Open Source Software) Enterprise Resource 
Planing Software YEROTH-ERP-3.0 [26]. 


Keywords: model-based testing - reactive system analysis - computer 
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1 Introduction 


1.1 Motivations 


This paper describes an effective dynamic analysis framework, based on run- 
time monitors specified in C++ programs (implemented in the software library 
yr_sd_runtime_verif), to perform software temporal safety property checking 
of GUI (Graphical User Interface) based software. 

GUI based software are very comfortable and handy to use. However, tools 
to perform temporal safety property verification of GUI software are allmost 
not available as FOSS. The testing of combinations between GUI windows and 
database queries that glue them to make sense to the user, is allmost unavailable 
as FOSS, or at all to the best of the knowledge of the author of this paper. The 
FOSS C++ library libfsmtest provides test suite generation support for 
source code behavior specifications as mealy automata. However, libfsmtest only 
allows for desirable correctness properties, and doesn’t provide GUI (interaction) 
support or as plugin-based. 

Unit or integration testing for GUI widgets is available by use of "NUnit" 
testing frameworks like e.g. Qt-Test [i], CppUnit [20], etc.. Software testing 
across GUI widgets (and MySQL queries) is however limited in support by 
these "NUnit" framework. To the best of the knowledge of the author of this 
paper, DejaVu [4] provides some support for Java’record and replay’ testing 
while FROGLOGIC [14] provides support for C++ GUI software ’record and replay’ 
testing technology. "Record and replay’ testing means a user performs a sequence 
of events that are recorded by testing infrastructure and automatically replay 
later on to see if expected events thereof occur. However, none of this ’record and 
replay’ technology tool enable temporal safety property specification as FOSS, 
with SQL as plugin. 

As we will see in the related work, section [7| of this paper, most of software 
correctness property checking frameworks don’t put an emphasis on checking 
temporal safety property of GUI software. Characterizing the effects of program 
statements (via SQL statements) on database table columns, and to check that 
these characteristics hold or not, is of predominant importance for large software 
systems with an impressive number of database tables. YEROTH-ERP-3.0 
has for instance 60 user interfaces (windows, dialogs), 38 SQL tables, 320 SQL 
table columns, and about 300,000 source lines of code. 

It means it can be very difficult for developers to keep application related 
logical requirements between the tables without appropriate software testing or 
analysis tools. 

A large amount of former work on runtime monitoring assumes for a sequential 
program, or an abstraction of the program as one single source code, on which 
program analysis is performed [7J9J3]6]10]. 

The program analysis technique the author of this paper presents here abstract 
SQL events, GUI events, or sequences of them, as a state diagram, and enables 
developers to run them sequentially against a runtime monitor specified as a C++ 
program. In particular, the example presented in Section [2] specifies results of 
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GUI windows events as SQL database pre-conditions on state diagram transitions; 
SQL events are specified as state diagram transition events. 


1.2 Main Contributions 


This paper presents 3 original main contributions: 


— an industrial level quality framework (YR_DB_RUNTIME_VERIF; https: //github 
com/yerothd/yr-db-runtime-verif), that solves temporal property ver- 


ification by dynamic program analysis. YR_DB_RUNTIME_VERIF makes use 
of the C++ Qt-Dbus library, to input a runtime monitor specification 
(yr_sd_runtime_verif) as C++ program code, that also enables software— 
library—plugin checks; 


— aC++4 library: (https: //github.com/yerothd/yr_ 


sd_runtime_verif); modeling a state diagram runtime monitoring interface 
using only set algebra inclusion operations (€, ¢) for state diagram program 
state specification as pre- and post-conditions. 

yr_sd_runtime_verif only enables the specification of states diagrams 
specifications as not desirable (forbidden) behavior specifications (fail 
traces). Thus, YR_DB_RUNTIME_VERIF doesn’t generate any false warning. A 
violation of a safety rule has been found whenever a final state could be 
reached. On the other hand, not reaching a final state doesn’t mean that 
there is not a test case (or test input) that cannot reach this final state. 


— An application of YR_DB_RUNTIME_VERIF to check 1 temporal safety property 
error, found in the ERP FOSS YEROTH-ERP-3.0. 


1.3. Overview 


This paper is organized as follows: Section [2] presents a motivating example that 
will be used throughout this paper to explain the presented concepts of this 
paper. Section |3} presents formal definitions of the principal concepts used in 
this paper. Section [4] presents the software architecture of YR_DB_RUNTIME_VERIF, 
our GUI dynamic analysis framework. Section |5| introduces the C++ soft- 
ware library yr_sd_runtime_verif to model states diagrams, and reused by 
YR_DB_RUNTIME_VERIF. We evaluate our dynamic runtime analysis in Section [6] 
Section [7] compares this paper with other papers that achieve similar work or 
endeavors. Section [8] concludes this paper. 
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2 Motivating Example: missing department definition 
Fig. 1: A motivating example, as current bug in YEROTH-ERP-3.0. 


Q0 := NOT_IN_PRE(YR_ASSET, department.department_name). 
Q1:=IN_POST(YR_ ASSET, stocks.department__name). 


True / select.department 


start 


Fig.3: YEROTH-ERP-3.0 


Fig.2: YEROTH-ERP-3.0 administra- stock asset window listing some 


tion section displaying departments (—Q0). 


Functions Tools Help 


assets (Q1). 
YEROTH-ERP-3.0 - asset and inventory stock listing 


Functions Tools Help 


e 


ASSET, STOCK Merchandise / 


Create Administration Modify Delete PURCHASE sea SERVICES 


Stockalert Commandsheet Category budgetline Bankaccount Useraccount Department Site Dis lilacs 


Department Product name Department —_ Total qty| Expiration date 


1 yeroth departement 1 


2 yeroth departement 2 
3 YR_ASSET 


Begin 01/01/2022 B * ITEMS 1 
filters End 11/02/2023 Inventory value 


type of inventory 


300.00 FCFA 


reset 


2.1 The Enterprise Resource Planing Software YEROTH-—ERP-3.0 


YEROTH-ERP-3.0 is a fast, yet very simple in terms of usage, installation, and 
configuration Enterprise Resource Planing Software developed by Noundou et 
al. for very small, small, medium, and large enterprises. YEROTH-ERP-3.0 
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Fig. 4: YR_DB_RUNTIME_VERIF command line shell output demonstrating that a 
final state has been reached (Section [6] analyzes these results). 


A yer@JH-NISSI: ~ Q =z Se ost 


is developed using C++ by means of the Qt development library. YEROTH-— 
ERP-3.0 is a large software with around 300 000 (three hundred thousands) of 
physical source lines of code. YR_DB_RUNTIME_VERIF could be used for integration 
testing of YEROTH-—ERP-3.0, among different software modules. 


2.2 Example Temporal Safety Property 


The motivating example of this paper consists of the temporal safety prop- 
erty stipulating that 7A DEPARTMENT SHALL NOT BE DELETED 
WHENEVER STOCKS ASSET STILL EXISTS UNDER THIS DE- 
PARTMENT”. This statement means that a user shall be denied the removal of 
department "YR_ ASSET” in Figure [2] because there are still a stock asset listed 
within department "YR_ ASSET”, as illustrated in Figure [3] Figurel]illustrates 
the above temporal safety property as a simple state diagram. 


State Diagram Explanation ’D’ is a start state as illustrated by an arrow 
ending on its state shape. ’E’ is a final (error, or accepting) state as illustrated 
by a double circle as state shape. 

The pre-condition QO (as a predicate) in state ’D’: 
’"NOT_IN_PRE(YR_ ASSET, department.department name)’ means: 


— a department named ’YR_ ASSET” is not in column ‘department _ name’ 
of database table ’department’. This might happen whenever button ’Delete’ 
in Figure [2] is pressed when item ’YR__ ASSET” is selected. 
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Similarly, the post-condition Q1 (as a predicate) IN_POST(YR_ ASSET, 
stocks.department name)’, in accepting state ’E’, means: 


— a department named ’YR_ ASSET’ ts in column ‘department _ name’ 
of database table ’stocks’. 


The state diagram event transition in Figure [I] ’select.department’ de- 
notes that when in ’D’, a SQL ’select’ on database table ’department’ has 
occurred; ’E’ is then reached as an accepting state. The source code speci- 
fied in Listing [1.3] also illustrates a specification in C++ using software library 
yr_sd_runtime_verif of the state diagram specification above. 


2.3 YR_DB_RUNTIME_VERIF Analysis Report 


The motivating example automaton in Figure is analyzed by 
YR_DB_RUNTIME_VERIF as follows: 


— Whenever department "YR_ ASSET” is deleted in YEROTH-ERP-3.0, as 
done in Figure [2} the runtime monitor state "D’ with a state condition QO is 
entered 


— when MySQL library (plugin) event ’select.department’ occurs, in Fig- 
ure [2] because of YEROTH-ERP-3.0 displaying the remaining product 
departments, the guarded condition for edge event ’select.department’ is 
automatically evaluated to ’True’ by C++ library yr_sd_runtime_verif, 
because no other guarded condition was specified by the developer 


— yr_sd_runtime_verif enters the runtime monitor state to ’E’ and 
state condition Q1 via method YR_trigger_an_edge_event (QString 
an_edge_event) because there are still assets (yeroth asset 3) left within 
product department ’YR_ASSET?’, as illustrated in Figure 
’E’ is then an accepting (or final or error) state. 


Figure [4] illustrates an analysis result of the afore described process, which 
gets evaluated and described in Evaluation Section [6] 


2.4 Runtime Analysis Interpretation Of yr_sd_runtime_verif Models 
By YR_DB_RUNTIME_VERIF 


The framework YR_DB_RUNTIME_VERIF assumes the following characteristics of a 
specification automaton in order to enable proper software integration testing: 


— the state diagram automaton only has 2 states: a start and a final state; 

— at most 1 state diagram transition pre-condition on the start state 

exactly 1 post-condition on the final state, that must hold, when the state 
diagram automaton reaches this final state 

exactly one state diagram transition between the start and the final state 
— no edge guard condition 


Future releases of yr_sd_runtime_verif will extend 2-states states 
diagrams mealy machines in order to have states diagrams with more 
than only 2 states. 
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3 Formal Definitions 


yr_sd_runtime_verif’s formal description of the state diagram formalism follows 
Mealy machine [29] added with accepting states (final or erroneous 
state), and state diagram transition pre- and post-conditions. Another 
excellent, detailed with proofs and theory presentation of mealy automata [27] 
is available. In comparison to statechart [16], which is a visual formalism 
for states diagrams, yr_sd_runtime_verif doesn’t support for instance the 
following features: hierarchical states (composite state, submachine state), timing 
conditions. 


Definition 1. A state diagram is a 8-tuple (S,59,C, ©’, A, 6,7, I’) where: 


— S: a finite set of states 

— So € S: a start state (or initial state) 

— C:a set of predicate conditions; pre-conditions are underlined (e.g.: QO), and 
post-conditions are overlined (e.g.: Q1). A pre-condition is comparable to a 
Harel-statechart guard condition. 

— %: an input alphabet, ©:= {F alse, True}. 

‘False’ means no input from SUT into YR_DB_RUNTIME_VERIF. 
‘True’ means any input could come from SUT. 

— A: an output alphabet (of program events e,(n € N)), ¢ the no program 
event. A program event generally corresponds to a function or method call 
at a SUT source code statement (or program point). 

— 6:5xC:a 2-ary relation that maps a state s to a state-condition c as either 
a state diagram transition pre-condition (c), or as a state diagram transition 
post-condition (¢). 

—T:SxS'> Sx A: a transition function that maps an input symbol to an 
output symbol and the next state. 


T: a set of accepting states; T € S. 


For instance, for the motivating example described in Figure [1] we have: 

S = {D,E}; So = D; C = {Q0, Ql}; = = {False,True}; 
A = {¢,’select.department’}; 6 = {(D,Q0),(E,Q1)}; T = 
{((D, False), (D,¢)), ((D, True), (E, ’select.department’))}; T = {E}. 


Definition 2. A pre-condition of a state diagram transition is a predicate that 
must be true before the transition can be triggered. A pre-condition QO could 
have 2 forms: 


— Q0 :=IN_PRE(X, Y) that means value "X" is in (€) database column value 
set "Y". 
— Q0:= NOT_IN_PRE(X, Y) that means value "X" is not in (¢) database 


column value set "Y". 
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Definition 3. A post-condition of a state diagram transition is a predicate that 
must be true after the transition was triggered. A post-condition Q1 could have 
2 forms: 


— Q1 :=IN_POST(A, B) that means value "A" is in (€) database column 
value set "B". 
— Q1:=NOT_IN_POST(A, B) that means value "A" is not in (¢) database 
column value set "B". 
Definition 4. A trace T,;, =< e°, e!, ..e" > is a sequence of SUT events (or 
SUT program points) e’(i € {0,..,n}) of length n. trace(D) is the trace of SUT 
events up to state D. For instance, for the motivating example described in 
Figure[1] we have: trace(D) =<>, trace(E) =< ’select.department’ >. 


Proposition 1: NO FALSE WARNINGS. yr_sd_runtime_verif only al- 
lows 1 outgoing edge or transition for a state in its specifications, and for not 
desirable (forbidden) behavior, as illustrated in Figure |1| There is no need to 
specify the red colored edge in Figure[1] because it represents runtime cases where 
no input events arrive from SUT into YR_LDB_RUNTIME_VERIF. These 2 properties, to- 
gether with algorithm ’YR_trigger_an_edge_event(QString an_edge_event)’ 
(Listing [1.1} of yr_sd_runtime_verif, ensures that there are no false warnings 
during YR_DB_RUNTIME_VERIF analyses. For example, the runtime monitoring or 
verification systems [7[9[3|6]10] may give false warnings. 


Listing 1.1: C++ Pseudo-code for YR_trigger_an_edge_event (QString 
an_edge_event): yr_sd_runtime_verif method for triggering state diagram 
events (edges or transitions). 


1 | bool MONITOR::YR_trigger_an_edge_event(QString an_edge_event) 
2 
3 MONITOR_EDGE cur_OUTGOING EDGE = cur_STATE.outgoing edge(); 
4 
5 if (cur_OUTGOING_EDGE.evaluate GUARDED CONDITION _expression() && 
6 (an_edge_ event == cur_ OUTGOING _EDGE.edge_event_token())) 
7 
8 bool precondition _IS_ TRUE = cur_OUTGOING_EDGE 
9 .CHECK_SOURCE_STATE_PRE_CONDITION(_cur_ STATE); 
10 
11 if (precondition _IS_ TRUE) 
12 
13 set_current_ triggered EDGE(cur_OUTGOING_EDGE); 
14 
15 MONITOR_ STATE a_potential_ accepting state = 
16 cur_ OUTGOING _EDGE.get_ TARGET_STATE(); 
17 
18 if (CHECK whether _ STATE __is__ Final(a_potential_accepting_state)) 
19 { 
20 CALL BACK __final_ state FUNCTION(a_potential_accepting state); 
21 
22 return true; 
23 } 
24 
25 return false; 
26 |} 
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4 The Software Architecture of YR-DB-RUNTIME-VERIF 


Fig. 5: YR_DB_RUNTIME_VERIF: simplified soft- 
ware system architecture. 


SUT source code instrumented 


Fig. 6: YR_DB_RUNTIME_VERIF and 
SUT socket communication (dia- 
gram inspired from Jan Peleska 


ciara wor. 


MYSQL library methods calls t 


QT socket calls (via Qt—Dbus) t 


OS system calls t 


SUT source code emits events as they occur. 


4.1 Dynamic Analysis 


SUT Source Code Instrumentation. YR_DB_RUNTIME_VERIF runs as a separate 
Debian Linux process from the application to dynamically analyze (YEROTH-— 
ERP-3.0 in this case). Figure [5]illustrates a software system architecture layer 
of a software system that uses YR_DB_RUNTIME_VERIF. Figure [5] and Figure (6 il- 
lustrate how YEROTH-ERP-3.0 is instrumented to send MySQL database 
events, as they occur on due to the GUI of YEROTH-ERP-3.0, to process 
YR_DB_RUNTIME_VERIF, so it can perform runtime analysis of the monitor imple- 
mented within it. 


Debugging Information. Each GUI manipulation of YEROTH-ERP-3.0 
in its instrumented source code part could generate a state transition within 
the analyzed runtime monitor state diagram in YR_DB_RUNTIME_VERIF. Visualize 
"line 35" of Figure [4] to observe that a specific analysis message is sent to the 
console of YR_DB_RUNTIME_VERIF in cases where a final state has been reached; 
the message at "line 33" is for an accepting (final) state of the state diagram 
specification of the motivating example presented in Figure [I] 


SQL Event Dbus Method Interface. YR_DB_RUNTIME_VERIF currently only 
handles 4 SQL events: DELETE, INSERT, UPDATE, SELECT. 


4.2 A Runtime Monitor (An Analysis Client) 
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Listing 1.2: "XML file adaptor for YEROTH—ERP-—3.0 test cases 
(reduced from 4 to only 1 SQL event for paper)." 


<!DOCTYPE node PUBLIC "—//freedesktop//DTD D—BUS Object Introspection 1.0//EN" 
"http: //www.freedesktop.org/standards/dbus/1.0/introspect.dtd" > 
<node name="/YRruntimeverification" > 
<interface name="com.yeroth.rd.TY Rruntimeverification" > 
<method name="YR_slot_ refresh SELECT DB MYSQL"> 
<annotation name="org.qtproject.QtDBus.QtTypeName.In0O" value="QString"/> 
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="uint"/> 
<annotation name="org.qtproject.QtDBus.QtTypeName.In2" value="bool"/> 
<arg type="QString" direction="in" /> 
<arg type="uint" direction="in"/> 
<arg type="bool" direction="out"/> 
</method> 
</interface> 


</node> 


Fig. 7: YR_DB_RUNTIME_VERIF: simplified class diagram in UML [8]. 


QDBusAbstractAdaptor 


tYRruntimeverificationAdaptor 


+YR_slot_refresh SELECT DB MYSQL(): bool 


YR_DBUS COMMON 
+_A RUNTIME MONITOR: YR DB RUNTIME VERIF Monitor 


+YR_slot_refresh SELECT DB MYSQL(): bool 


dbusflient» 


YR_DB_RUNTIME_VERIF_Monitor 


+YR_slot_refresh SELECT DB MYSQL(): bool 
+DO_VERIFY_AND_or CHECK ltl PROPERTY(): bool 


+YR trigger_an edge event(): bool 


An user (an analysis client) of YR_DB_RUNTIME_VERIF needs to subclass class 
YR_DB_RUNTIME_VERIF_Monitor. The UML class diagram in Figure [7] displays 
the class structure of YR_DB_RUNTIME_VERIF. Qt-Dbus communication adaptor 
TYRruntimeverificationAdaptor shall be generated by the user of this library 
(on ¥YR_DB_RUNTIME_VERIF side) using Qt-Dbus command qdbusxml2cpp and an 
XML file, similar to the one displayed in Listing [1.2] 

An analysis client must first override method 
"DO_VERIFY AND_ or _CHECK_ lt] PROPERTY’ of class 
*YR_DB_RUNTIME_VERIF_Monitor’ so to implement a checking algorithm for 
each event received from SUT, as for instance the events illustrated in 
Figure }1| of the motivating example. The analysis client then calls method 
*YR_trigger_an_edge_event(QString an_edge_event)’ (Listing [1.1) of class 
"YR_CPP_RUNTIME_MONITOR’ of C++ library yr_sd_runtime_verif for each 
corresponding state diagram transition event. 
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5 yr_sd_runtime_verif: A C++ Library to Model States 
Diagrams 


Fig. 8: Class diagram in UML [8] to model 


a State Transition Diagram. 


YR_CPP_MONITOR 
DGE: T 


+is_in SET ALGEBRA(a_SET VARIABLE: 05tring, 
a SUPPOSED SET VARIABLE:QString) : bool 


Fig. 9: Class diagram in UML [8] 
to model state diagram tran- 


1. 


sition trace conditions in 
yr_sd_runtime_verif code. 


+evaluate expression(): bool 


1 


YR_CPP_not_in_SET_TRACE_expression 


+evaluate expression(): bool 


YR_CPP_MONITOR_TRACE_EVENT = r. 


YR_CPP_BOOLEAN expression 


YR_CPP_in_SET TRACE expression 
SYS 
+evaluate expression(): bool 


5.1 Structure Of yr_sd_runtime_verif 


yr_sd_runtime_verif is a state diagram C++ library the author of this paper 
created to work with the dynamic analysis program YR_DB_RUNTIME_VERIF. Figure[§| 
and Figure /9|represent the class structure, in UML, of yr_sd_runtime_verif. 
Listing fn the C++ code that models the motivating example in 
Figure and that uses runtime monitoring C++ state diagram library 
yr_sd_runtime_verif. 

There is no need to write C++ code for the red specified edge of 
Figure | 1} this represents runtime cases where no input event arrives 
from SUT into YR_DB_RUNTIME_VERIF. 


5.2 Methods for Pre- and Post-Condition Specifications 


Table 1: yr_sd_runtime_verif Methods for Pre-/Post-Condition Specification 


Class YR _CPP_MONITOR_ EDGE Methods Utility 


set PRE CONDITION _notIN(QString, QString) |sets a NOT IN DATABASE pre-condition 
set PRE CONDITION _IN(QString, QString) sets an IN DATABASE pre-condition 

set POST CONDITION _ notIN(QString, QString)|sets a NOT IN DATABASE post-condition 
set POST CONDITION _IN(QString, QString) sets an IN DATABASE pre-condition 
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Listing 1.3: yr_sd_runtime_verif C++ code modeling a current bug in 
YEROTH-ERP-3.0 (Figure [Ip. 
YR_CPP_MONITOR_EDGE xa_last_edge_0 = create_yr_monitor_edge("D", 

Wig 

"select.departements_ produits"); 


a_last edge 0—>get_ SOURCE_STATE()—>set_START_STATE(true); 


a_last edge 0—>get_ TARGET _STATE()—>set_FINAL_STATE(true); 


a_last edge _0—>set_PRE CONDITION notIN("YR_ASSET", 
"departements produits. 
nom_departement produit"); 


CUOANOURWNFH 


BR 


12 |a_last_edge O—>set_POST_CONDITION_IN("YR_ASSET", 
13 "stocks.nom_departement_ produit"); 


15 | YR_register_set_final_ state CALLBACK FUNCTION(& 


YR_CALL_ BACK _final_ state); 


Table |1| illustrates methods for specifying pre— and post—conditions of a 
runtime monitor state diagram transition. Each method takes in 2 arguments of 
string (’QString’) type: ’DB_VARIABLE’, ’db_TABLE__db_COLUMN’. 

The first method argument: ’DB_VARIABLE’, specifies which variable is to 
be expected as value for the specification of the second variable argument 
*db_TABLE__db_COLUMN’. The second variable gives in a string to be specified 
in format "DB_table_name.DB_ table column"; and its supposed value is the 
returned value of the first variable argument ’DB_VARIABLE’. 

These 4 pre- and post-conditions methods make assumptions that a program 
variable value ’DB_VARIABLE’ is in set "DB_table_name.DB_table_ column" 
or not; if the value of ’DB_VARIABLE’ is in the database table column, it means 
it is in the set (€) of values "DB_table_name.DB_table_ column"; and not 
being in the table column means it is not in the set (¢). 


Example from the motivating example in Section Listing [1.3] of the 
runtime monitoring specification stipulates for instance in its "line 12", as post- 
condition: 


a_last_edge_0->set_POST_CONDITION_IN("YR_ASSET", 
"stocks.nom_departement_produit") ; 


that "YR ASSET” shall be a value in the value set (€) of SQL table 
*stocks’ column ’nom_departement produit’. 
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6 Evaluation 


The main experimental results in this paper demonstrate the efficacy of our tool 
to find errors in the SUT (YEROTH-ERP-3.0), presented in Subsection [2.2] 


Table 2: SUT (YEROTH-ERP- 3.0) Trace Output (Figure|4). 


| CONSOLE OUTPUT LINE SQL EVENT SUT PROGRAM POINT (TRACE) 

| 21 "DELETE.department.YR_ ASSET" )"src/admin/lister/yeroth-erp-admin-lister-window.cpp:1603" | 
| 22 "DELETE.merchandise.YR_ASSET"|"src/admin/lister/yeroth-erp-admin-lister-window.cpp:1626 "| 
| 23 "SELECT .department" "sre/yeroth-erp-windows.cpp:967" 


Qualitative Results. 


SUT (YEROTH-ERP-3.0) TRACING. Table [2] illustrates SUT source code 
trace information as presented in YR_DB_RUNTIME_VERIF console output in Figure[4] 
We have translated from French to English the MariaDB SQL table names. 


SQL EVENT CALL SEQUENCE. A careful observation of the output in Figure[4] 
illustrates the following sequence: 


— line 23: at state D, execution of the state diagram event "’select.department’ 
" (SUT button ’Delete’ has been pressed at line 21) : 


select * from departements_produits WHERE nom_departement_produit = ’YR_ASSET’; 


— line 28, line 29: evaluation of the pre-condition QO of state D stating that 
product department "YR_ ASSET” is not existent evaluates to "TRUE’ (trig- 
gering of event "delete.department.YR_ ASSET " by pressing of SUT button 
‘Delete’ at line 21 has removed any asset department name "YR_ ASSET”). 


*[YR_CPP_MONITOR: : CHECK_PRE_CONDITION_notIN:] precondition_IS_TRUE: True =e 


— line 31, line 32: checking post-condition Q1 in state EF (there are still stocks 
in stock department "YR _ ASSET’) evaluates to TRUE’, thus state E is 
reached as an accepting state, because department name ’YR_ ASSET” still 
exists in SUT SQL table "stocks", as illustrated in Figure [3] of the motivating 
example: 


"execQuery: select * from stocks WHERE nom_departement_produit = ’YR_ASSET’;" 
*[YR_CPP_MONITOR: : CHECK_post_condition_IN:] postcondition_IS_TRUE: True bide 


Runtime Performance. YR_DB_RUNTIME_VERIF and yr_sd_runtime_verif 
don’t incur a runtime supplemental overhead to the SUT, apart from emit- 
ting SQL events from SUT to YR_DB_RUNTIME_VERIF as they occur, since no 
hand-shaking mechanism is used between YR_DB_RUNTIME_VERIF and the SUT. 
The emission of an SQL event from SUT to YR_DB_RUNTIME_VERIF doesn’t cost 
more than 2 statements execution time (getting a pointer to the DBUS server, 
and calling a method ’YR_slot_refresh_SELECT_DB_MYSQL’ or other similar 3 
methods (for INSERT, UPDATE, and, DELETE) on it). 
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Related Work 


— SUT source code instrumentation with specification. "Clara" [7] 


enables to express software correctness properties using AspectJ and de- 
pendency state machines, both as instances of the typestate formalism, a 
formalism that is merely used for checking correctness of programs by a static 
compilation (analysis) technique called typestate checking. The Clara 
framework weaves (instruments), and annotates a program with runtime 
monitors using AspectJ, then tries to optimize the weaved program by static 
analysis. The "residual program”, meaning the weaved statically optimized 
program is then executed and runtime monitored by developers to detect 
runtime errors. Runtime monitoring tools |9/3/6}10) work as similar as the 
Clara framework does. 


SUT binary code instrumentation with a runtime monitor. With 
tracerory [13[12|", Jon Eyolfson and Patrick Lam use runtime program 
binary code instrumentation technique in INTEL-pin [24] to instrument 
running programs for purposes of detecting unread memory. I.e., tracerory 
doesn’t generate itself a runtime monitor, it uses INTEL-pin [24] to generate 
a runtime monitor for its verification purposes. "Purify" [[7] doesn’t allow 
for SUT user correctness property specification. It has built-in memory access 
safety properties to check offline on program execution, after instrumentation 
of the SUT, its third-party, and vendor object-code libraries. 


Specification as set interface operations. "Hob" is a program 
verification framework that enables to: characterize effects of program state- 
ment on data structures by means of all (V, 4, etc.) algebra abstract set 
interface operations; and to check that these characteristics hold or not, using 
static analyses. 


Concurrent Event Stream Analysis. 

"DejaVu " [19] enables to check safety temporal property expressed in 
first-order past linear-time temporal logic (FO-PLTL) for events 
that carry data. DejaVu inputs a trace log (offline) and a FO-PLTL for- 
mula, and outputs a boolean value for each position in the inputted trace. 
"LoGScopPE" [18] checks, offline, software systems correctness properties 
expressed using a rule-based specification language over state machines. It 
is not very precise what type of state machine is created and processed. 
"LOGScoPE" translates specifications into C++ monitors (that could carry 
data). "EventRaceCommander" [2] repairs in web applications (online), event 
race errors, a kind of safety error. 
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8 Conclusion And Future Work 


This paper has presented a lightweight C++ Qt-Dbus [21] tool to check a program 
against a runtime monitor using set interface operations (€, ¢) on program state- 
ment: YR_DB_RUNTIME_VERIF. YR_DB_RUNTIME_VERIF doesn’t generate false warnings; 
YR_DB_RUNTIME_VERIF specifications are not desirable (forbidden) specifications 
(fail traces). Since the concurrent communication between YR_DB_RUNTIME_VERIF 
and a program occurs over the RPC (Remote Procedure Call) instance Dbus, 
a runtime monitor could be checked against programs written in any program- 
ming language or framework, as long as they emit the necessary SQL events to 
YR_DB_RUNTIME_VERIF. 


Fig.10: A Mealy Machine State Diagram Specified Using 
yr_sd_runtime_verif Specification Language. 


1. yr_sd_mealy_automaton_spec yr_missing_department 

22.4 

3. START_STATE(d) :NOT_IN_PRE(YR_ASSET, departements_produits.nom_departement_produit) 
4. -> / ’select.departements_produits’-> 

5 FINAL_STATE(e) : IN_POST(YR_ASSET, stocks.nom_departement_produit) . 

6. } 


Future work would be an algorithm within yr_sd_runtime_verif, to ex- 
tend 2-states state diagram mealy machine so to retrieve more states. The 
author of this paper has created a DSL (domain-specific language) and a 
compiler (yr_sd_runtime_verif_lang_comp that enables automatic gen- 
eration of yr_sd_runtime_verif C++ state diagram specification code for 
YR_DB_RUNTIME_VERIF; an example specification is to find in Figure 


Fig. 11: ’yr-qvge’ model for the example specification in Figure [10] 


START_STATE(d): STATE(e): 
NOT_IN_P s 7 = a YR_ASSET, 
department.departryent_name) .departrpent_name). 


Also, the author of this paper has developed a graphical drawing tool 
(yr-qvge) for in Section [3] defined state diagrams. A model of yr-qvge is shown 
in Figure [11] It is an extension of the FOSS (Free and Open Source Software) 
Qt Graphviz [15] drawing tool QVGE [28]. yr-qvge generates, from a model, an 
input file for the compiler yr_sd_runtime_verif_lang_comp. 
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